Repository navigation
Conversation
Composite actions, scripts and example workflows for building, packaging and releasing MODFLOW program repositories, generalized from mfusg's workflows. Moved from MODFLOW-ORG/release-tooling, so the actions are versioned with modflow-devtools. Co-Authored-By: Claude Opus 5.5 <[email protected]>
wpbonelli
changed the title
actionlint 1.7.7 rejects YAML aliases for on.<event>.paths. Co-Authored-By: Claude Opus 5.5 <[email protected]>
Move the release-start/finish logic into modflow_devtools/release/workflow.py so it can be tested, and make each stage safe to rerun. Fail before the build when a release has no changelog section. Support extra release assets, drop Intel macOS, take gfortran from pixi and always link compiler runtimes statically, enforce static linkage on every platform, package the same way everywhere, use only the shared git-cliff template at a pinned version, scope the meson version to project(), and update version files atomically. Co-Authored-By: Claude Opus 5.5 <[email protected]>
On Windows, --prepend repeated the changelog header. Insert the new section above the earlier ones in Python, and write the file with LF line endings. Co-Authored-By: Claude Opus 5.5 <[email protected]>
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Shared CI/release tooling for program repos, generalized from mfusg's workflows
setup: Intel compilers via setup-fortran, gfortran from the repo's pixi environment (conda-forge), static linking viaLDFLAGScheck-linkage: fail on dynamically linked compiler runtimes on every platform/compiler toolchain, require arm64 on macOSpackage: zipbin/as<ostag>.zipand the source as<name>_source.zip, identically on every platformrelease-startrelease-finish: publish with optionalextra-assetsversionchangelogversionchangelogpackageworkflowdocs/examples/for program repos to copygit-clifftemplatecliff.toml, used by every repo, git-cliff pinned and run withpipx/uvxmain) and dual (develop->main) branching modelsThe idea is for each program repo to own its workflows, since they may vary too much to share, but define shared scripts/actions/conventions here. Moving some logic into Python should help if God forbid we are ever forced off GitHub to another git forge/CICD platform.
Test release stuff against a local bare git remote and a fake
gh, including reruns.